Centralised interactive graphical application server

ABSTRACT

This invention relates to a method of processing a plurality of graphical programs on a centralized computer system whereby the images produced by the programs are compressed and transmitted to remote processing devices where they are decompressed. Compression assistance data (CAD) is produced by inspecting instructions outputted by the programs and the CAD is then used in the compression step.

This application claims the right of priority to, and is a continuationof, U.S. patent application Ser. No. 13/298,266, which in turn claimsthe right of priority to U.S. patent application Ser. No. 13/032,401(Now issued as U.S. Pat. No. 8,081,192), which in turn claims the rightof priority to U.S. patent application Ser. No. 10/506,151, (Now issuedas U.S. Pat. No. 7,916,147), which in turn claims the right of priorityto PCT application No. PCT/GB2003/00933, internationally filed Mar. 3,2003, which claims the right of priority to United Kingdom patentapplications No. 0226192.3 filed Nov. 9, 2002, 0223687.5 filed Oct. 11,2002, and 0204859.3, filed Mar. 1, 2002. All the above identifiedapplications and patent documents are incorporated herein by reference.

This invention relates to operation of interactive software such asgames software and in particular object identification and motionestimation in image compression for improved hosting of the software ona centralised computer platform.

In the field of interactive software such as games, typically, someonewanting to run the interactive software or game may do so using a PC(Personal Computer) or game console such as a Nintendo™ GameCube™ orSony™ Playstation 2™. The latest games software requires machines withpowerful processors and graphics renderers. Each new release of softwaretaxes the capabilities of the hardware to its limits obliging the ownerof the hardware to suffer the expense of having to regularly update orreplace their hardware.

A further problem with the typical situation is that there are a numberof different hardware platforms. A game that runs on the Sega Dreamcast™will largely need to be re-written to run on a PC or Sony Playstation™.It is therefore expensive for a game developer to fully exploit themarket potential of a game whilst consumers must own the appropriatehardware before being able to enjoy a particular game.

There are a variety of known related technologies, which are describedbelow.

Games servers allow for multi-player games such as Quake™ and simply actas central gateways that communicate the location and actions of all theother players participating in a given game. Each player will still needa local copy of the game and a local device capable of processing thesoftware and rendering all the images associated with the game.

Games streamer technology splits a game up into chunks, allowing a userwanting to download a game to commence playing before the whole game hasbeen downloaded. Downloading continues whilst the game is played. Thisis simply a more convenient way of distributing the software.

Graphics streaming technology streams the graphics elements such as themeshes (wire-frame descriptions of objects) and textures (‘skins’).Amongst others, MPEG-4 (Motion Pictures Expert Group), which is astandard for compressing moving pictures and audio data and forsynchronising video and audio data streams, includes methods ofcompressing meshes and textures for transmission to a remote renderer.Systems utilising this technology will still need a powerful clientcapable of rendering the images whilst the game itself could be run on aclient or server machine.

Web-based games use technologies such as Java™ or Shockwave™ to offergames via Web pages. However, rather than being processed on the server,although the graphics elements might have been compressed, the softwareis still run on the user's client machine and the graphics is stillrendered at the client too.

Centralised game servers are another known technology, which are theparticular field of the present invention. By processing the game andrendering images on a central server, users can play games connected toa broadband telecommunications network, such as Digital Subscriber Line(DSL), cable or third generation (3G) wireless network.

Such systems remove the necessity of purchasing a dedicated (andexpensive) games console or for a PC to be constantly upgraded with thelatest processor and graphics card. People wishing to play a game mayinstantly subscribe to a games service via their cable TV company usingtheir already installed set top box. Cable TV companies thus find a newrevenue stream, games developers have access to a wider market withlower distribution costs and end users have the opportunity to dabblewith games without having to invest in expensive, dedicated equipment.

Although these networks have relatively high bandwidths when compared toa normal telephone line, the graphics images for high-end games stillneed to be heavily compressed before transmission. Such a compressionsystem needs to be very fast so that the overall system latency does notdetract from the game playing experience.

Instead of each user having their own ‘intelligent’ devices that arecapable of rendering the complex graphics of modern games, theprocessing is undertaken at a central server. The images relating to thegame are compressed at the hub and transmitted over broadband networksto the end users who use relatively ‘dumb’ terminals to view the imagesand interact with the games software running on the central server.

This central server needs to be powerful enough to run multiple copiesof games software, the compression system and the transmission system sothat it can serve a large number of simultaneous users who may beplaying different games at the same moment.

The further advantages of such a centralised game servers are:

-   -   users do not have to possess dedicated hardware powerful enough        to play the latest games;    -   by re-utilising the same equipment the service provider        (typically a cable TV or telecommunications company) may offer        this service far more cost effectively than by providing each        customer with a games console or PC;    -   games developers may have access to a wider audience as it is no        longer dependent on the user possessing the appropriate        hardware, merely connection to a broadband network which may be        to the home, office or via e.g. a 3G or “WiFi” wireless network,        to a mobile device;    -   games updates and bug fixes can be instantly and automatically        incorporated; and    -   online, multi-player cheating may be curtailed by blocking the        ‘cheat modes’.

However, to make such a system work there are two technical problemsthat have to be overcome:

-   -   quality of compression: the images have to be heavily compressed        so as to be able to be transmitted over the typical domestic        broadband network such as cable TV or DSL; and    -   network latency: the compression system has to work very        quickly. The delay between the user pressing a control, the        associated command being processed by the server, the new scene        being calculated, compressed, transmitted and then decompressed,        has to be negligible to the user.

U.S. Pat. No. 5,742,289 to Lucent, Murray Hill, N.J., discloses a systemthat encapsulates the games processing with graphics rendering andencoding in a centralised game server. As such it can compress asynthetic image in parallel with the rendering of that image. The patentdiscloses a system and method with the features of a computer graphicssystem, including MPEG encoding. The system uses a detailed model of 2Dimages, including motion vectors and passes compression assistance dataforward to an encoder, so as to simplify the encoding process. Thecomplete system includes a shared database of 3D images, hybridrendering engines and a connected video encoder.

Generally, game graphics are rendered using a dedicated graphicsprocessor, referred to herein as a Graphics Processing Unit (GPU). Aproblem with the system of U.S. Pat. No. 5,742,289 is that it does notallow the use of standard graphics processors and will therefore need alarge number of general processors as well as specially written softwareto perform the graphics processing. Furthermore, the games software willhave to be specially written to run on this new processing platform.

The article “Accelerated MPEG Compression of Dynamic Polygonal Scenes”,Dan S. Wallach, Sharma Kunapalli and Michael F. Cohen, Computer Graphics(Proc. SIGGRAPH 1994), July 1994 describes a methodology for using thematrix-vector multiply and scan conversion hardware present in manygraphics workstations to rapidly approximate the optical flow in ascene. The optical flow is a 2D vector field describing the on-screenmotion of each pixel. An application of the optical flow to MPEGcompression is described which results in improved compression withminimal overhead.

The system stores the transformation matrices from two frames and usesan “identity texture” which it projects onto all objects in a scene sothat it can find the relationship between an object and the screen. Theproblem with this approach is that it only works with matrices. Itdoesn't cope with GPU vertex shader programs which may for example usecosines to emulate ripples across water.

Overall, a first problem with the known approaches is that they assumethat the transformations of vertices are done on a Central ProcessingUnit (CPU) so that the results are stored in local memory and are easilyextracted. This means that a game has to have routines enmeshed in it toperform the compression-related tasks. It would be advantageous not toneed to have specially written game code.

A second problem, when a GPU is used, is that because the GPU doesn'tnaturally store the results of the vertex transformation process specialtechniques are required to extract and store that data.

It would be advantageous to provide a system that is capable of beingrealised using standard components in a modular fashion to produce acommercially viable solution to these problems.

It is an object of the present invention to improve the quality ofcompression and reduce latency in hosted interactive graphical systems.

According to a first aspect of the present invention, there is provideda method of generating a compressed video data signal using at least onegraphics processor module, comprising:

a) receiving a first set of instructions for a graphics processormodule;

b) intercepting said first instructions and generating a second set ofinstructions for a graphics processor module;

c) processing said first set of instructions or said second set ofinstructions in a graphics processor module to generate first graphicsdata;

d) processing said second set of instructions to generate secondgraphics data;

e) processing said second graphics data to generate compressionassistance data; and

f) processing said first graphics data, using said compressionassistance data, to generate a compressed video data signal.

According to a second aspect of the present invention there is providedapparatus for generating a compressed video data signal, the apparatuscomprising at least one graphics processor module, the apparatuscomprising:

a) an instruction interception function for receiving a first set ofinstructions for a graphics processor module and generating a second setof instructions for a graphics processor module;

b) a processing function for processing said first set of instructionsor said second set of instructions in a graphics processor module togenerate first graphics data;

c) a processing function for processing said second set of instructionsto generate second graphics data;

d) a processing function for processing said second graphics data togenerate compression assistance data; and

e) an encoding function for processing said first graphics data, usingsaid compression assistance data, to generate a compressed video datasignal.

The present invention may be used to improve the quality of compressionfor computer-generated graphics. There are a number of compressiontechnologies currently available, all of which are constantly evolving.To maximise flexibility it is therefore important to have as modular asystem as possible so that the compression stage could be replaced orupdated without affecting the integrity of the complete solution.

One example of a compression technology is the industry standard MPEG-4.It is unusual in that it doesn't define how images should be encoded,just the protocol of the bit-stream and the method of decoding. It alsoprovides a toolkit of compression methods. The decision process of whenand how to apply them will vary from one implementation to anotherresulting in vastly different quality images and compression ratios.

One option available to an MPEG-4 encoder is the encoding of separategraphical objects within an image. For example, a walking figure asdistinct from the background image of a field through which that personis walking. Although encoding the walking figure as a separate objectcan yield higher compression ratios, to isolate an object from abackground scene is a complex and processor-intensive process.

An advantage of working with synthetic video such as from computergraphics is that the individual constituents (objects) of that image areknown. In the case of natural video an encoder must first deconstructthe image. Here, by extracting the object definitions before the imageis rendered the processing load is lessened.

According to preferred embodiments of the invention, compressionassistance data includes motion vector data. Some examples of othertypes of compression assistance data which may be provided when encodingimages with MPEG-4 data compression are:

-   -   which parts of a scene—if any—to encode as separate objects (as        there is a maximum number)    -   what form of encoding to use on the objects    -   whether to encode the shapes as transparent objects or solids    -   how often to transmit full images rather than simply changes        from a previous image (as there is a trade-off between error        corrections and bandwidth)    -   whether or not to use overlapped motion estimation.

The criteria used in making these decisions include:

-   -   processing time/effort required to make an analysis    -   the bandwidth ‘budget’ left    -   minimum image quality constraints.

The present invention may also be used to improve network latency.Network latency is dependent on the speed of the encoding sub-systemwhich in itself is a trade-off between the quality of compression andthe processing power required. To improve speed the present inventionseeks to process some of the encoding steps in parallel to the renderingof the image to be compressed. Furthermore, it seeks ways in whichinformation about the image can be easily extracted without having toreverse engineer it as would normally be the case with a natural videoimage.

This invention therefore has been developed within the following designconstraints:

-   -   modularity (separation of the functions of processing of the        games software, rendering of the images, encoding of the images)        for ease of debugging and upgrading    -   ability to run existing games software with minimal (or even        better no) changes    -   ability to use off-the-shelf components wherever possible e.g.        with a graphics processor.

The instruction interception function may be a device driver.Alternatively the instruction interception function is a wrappercomponent for DirectX™ or OpenGL™.

The instruction interception function may be adapted to input differentinstructions to different graphics processor modules.

Optionally a plurality of instruction interception functions may each beadapted to input different instructions to different graphics processormodules.

Preferably the instructions comprise graphical data. Optionally, theinstructions may comprise program code. Preferably the instructionscomprise textures.

Optionally a difference between different instructions compriseslighting instructions. Preferably a difference between differentinstructions comprises shading instructions.

Preferably, the instructions further comprise 3 Dimensional sceneinformation. The same 3 Dimensional scene information may be fed to eachgraphics processor module.

Preferably the instructions fed to a first graphics processor modulecomprise textures and the instructions fed to a second processor modulecomprise different new object textures. In one embodiment each of thenew object textures is a unique texture for each object in an imageframe. Preferably the new object textures are determined so that no twoof the textures of neighbouring polygons of an object are the same. Thenew object textures may be re-orientated in subsequent frames of video.In one embodiment the new object textures are flat colours.

Alternatively the instructions fed to at least one graphics processormodule cause it to generate new object textures.

In one embodiment the relationship between a part or parts of an objectand its 2D screen representation is rendered into temporary storage forcomparing between two or more frames. Preferably it is stored as atexture. Preferably there is one of these textures per object, more thanone, or one that is shared by all objects.

In one embodiment, texture to vertex mappings are remapped to attain a“unique texture space” by adding a constant offset. Preferably thetexture to vertex mappings are remapped to attain a “unique texturespace” by varying the offset.

Alternatively a “unique texture space” may be attained by creating a newtexture of the same size and dividing it into a larger number ofpolygons as in the original and then remapping the object vertices to aunique polygon from the new texture.

In one embodiment a ‘reference’ texture that corresponds to the pixelsof a screen is projected onto a scene for the purpose of identifyingwhere each portion of an object appears on the screen at any moment intime. Preferably the instructions fed to at least one graphics processormodule cause it to generate a single texture that covers the entirescene that makes up an image frame and combines with existing surfacesof the objects in said scene to produce new object textures. Typicallysaid single texture is projected onto objects within a scene. Preferablythe step of generating a single texture further comprises setting thesurface of an object to a default and then altering the single textureso as to create and apply a new surface texture for the object.Preferably the default indicates whether the object is translucent, andpreferably the default is unique to each object in an image frame.

In one embodiment, the assistance data generating function is adapted todetermine the shapes of objects responsive to the second graphics data.

In another embodiment the assistance data generating function is adaptedto determine the positions of image elements responsive to the secondgraphics data.

Preferably the encoding function is adapted to pick out individual imageelements from an image rendered by the first graphics processor moduleresponsive to the compression assistance data.

Optionally, a new object texture may be used to signify to the encodingfunction that an object is translucent.

Preferably the encoding function is adapted to detect a complete scenechange. More preferably the encoding function is adapted to use adifferent compression method responsive to detection of a complete scenechange.

Preferably, the or each graphics processor module comprises a dedicatedgraphics processor, typically in the form of a graphics chip.Optionally, two or more dedicated graphics processors are used which arefunctionally substantially identical.

Alternatively, the function of more than one graphics processor modulemay be implemented on a single dedicated graphics processor, for exampleusing a multiple time slice processing scheme.

A graphics processor module may be shared between one or morecompression sub-systems. A single dedicated graphics processor may beclocked to render frames at a higher frequency than the final displayrate.

Preferably, rendered frames are stored in a buffer memory for theencoding function to process.

Handshake signalling may be used between the encoding function and theinstruction interception module to co-ordinate the process.

Preferably the new object textures may comprise a numerical valuevarying corresponding to position in the frame.

More preferably, the new object textures comprise one numerical valuevarying corresponding to the horizontal co-ordinate, and another onenumerical value varying corresponding to the vertical co-ordinate.

Preferably the assistance data generating function is adapted to detectmotion between frames by comparing object textures.

Optionally, the assistance data generating function is adapted to detectmotion between frames by comparing the pixels on objects against thosein a texture that had previously been applied across the entire imageframe.

Optionally, the assistance data generating function is adapted to detectmotion between frames by comparing information “tagged” to one or morevertices that form part of an object or that relate to that object'sposition. The tags may for example be colour values. The tags mayalternatively include other data that are associated with the vertices.

Typically the tags are used to influence the rendering process so thatthe position of said vertices can be readily identified when the objectsthey relate to are rendered. The rendering may for example be influencedthrough varying the colour or brightness of pixels in the renderedimage.

Optionally, the assistance data generating function is adapted to detectmotion between frames by comparing the relationships between a part orparts of an object and its 2D screen representations whereby suchrelationships had previously been rendered into temporary storage. Thestorage may be of one or more textures per object or a texture shared bymore than one object.

Optionally the comparison of the pixels on an object may be against anotional, fixed grid or point. Typically, the comparison comprisesmasking selected bits at least one pixel co-ordinate. Preferably thecomparison comprises at least one subtraction. Preferably thesubtraction only occurs where said textures belong to the same polygonof the same object. Optionally the comparison further comprises the stepof aggregating the results of said subtraction. Typically theaggregation comprises averaging. Optionally the aggregating comprisesdeducing a mean.

Preferably the assistance data generating function is adapted togenerate a motion vector for an entire block by aggregating the motionvectors of the parts of the objects that occupy that block. Typicallythe aggregating comprises averaging. Optionally the aggregatingcomprises deducing the mean.

Preferably the assistance data generally function is adapted to generatea motion vector for an entire object by detecting which pixels in eachof the blocks belong to a given object, comparing these pixels withthose in the same location in another frame and aggregating the comparedpixels to deduce the motion vectors of that object. Typically,aggregating the detected pixels comprises averaging. Typically, thecomparison comprises masking selected bits at least one co-ordinate.Preferably, the comparison comprises subtraction at least oneco-ordinate whereby said textures belong to the same object. Preferably,the entire object to which a motion vector applies includes all theblocks that are deemed to be associated with an object.

Optionally, parameters from the instructions fed to a first graphicsprocessor module are stored and then processed with parameters from asecond frame to thereby determine an inter-frame difference that formspart of compression assistance data.

In an alternative embodiment of the invention, the second set ofinstructions includes a modified or new set of program code for aprogrammable pipeline module such as a vertex shader program or pixelshader program.

The method may include executing a program on a programmable pipelinemodule to process first parameters thereby determining a firsttransformation result, and executing the program on the programmablepipeline module to process second parameters thereby determining asecond transformation result.

Typically the transformation result directly relates to a screenposition and a determined inter-frame difference value may be determinedin the form of a motion vector.

Optionally the transformation result is a colour and the determinedinter-frame difference value is a difference in chrominance orluminance.

Preferably the method further includes analysing a first program for aprogrammable pipeline module to determine those instructions that do notinfluence the state of an object in a frame that is used for thecompression assistance data and creating a second program for aprogrammable pipeline module in response to the determined instructions.

Preferably the step of analysing the first program for a programmablepipeline module includes determining which parameters influence theposition transformation of an object and storing the determinedparameters.

Optionally the step of analysing the first program for a programmablepipeline module includes determining which parameters influence thecolour or brightness of an object and storing the determined parameters.

Preferably the first program for a programmable pipeline module and thesecond program for a programmable pipeline module are executed on thesame graphics processing module.

Alternatively, the first program for a programmable pipeline module andthe second program for a programmable pipeline module are executed ondifferent graphics processing modules.

Preferably a device driver or wrapper around the graphics ApplicationProgramming Interface (API) (sometimes referred to as middleware) for agraphics processing module is adapted to reserve program storage spacefor a programmable pipeline module on the graphics processing module byreturning a reduced value of available program storage space oninterrogation of the device driver.

More preferably a device driver or wrapper around the graphics API for agraphics processing module is adapted to reserve data storage space fora programmable pipeline module on the graphics processing module byreturning a reduced value of available data storage space oninterrogation of the device driver.

In order to provide a better understanding of the present invention, anembodiment will now be described by way of example only, with referenceto the accompanying Figures, in which:

FIG. 1 illustrates in schematic form a centralised interactive graphicalapplication system in accordance with the present invention;

FIG. 2 illustrates in schematic form a typical pipeline for theprocessing of a game;

FIG. 3 illustrates the typical processing flow of rendering a scene by agraphics processor;

FIG. 4 illustrates a texture being projected onto a simple 3D scene;

FIG. 5 illustrates an overview of a gaming system according to oneembodiment of the invention;

FIG. 6 is a schematic diagram illustrating a single games serveraccording to an embodiment of the invention;

FIG. 7 illustrates, in schematic form, a vertex shader;

FIG. 8 illustrates, in schematic form, the architecture in accordancewith a preferred embodiment of the present invention;

FIG. 9 illustrates a flowchart of the steps for the processing of afirst frame in accordance with a preferred embodiment of the presentinvention; and

FIG. 10 illustrates a flowchart of the steps for the processing of asecond and subsequent frames in accordance with a preferred embodimentof the present invention

The present invention relates to a system for interactive applicationsthat functions to generate compressed data streams representing videoimages which include computer-generated graphics. Information relatingto the field of computer-generated graphics can be found in the textbook“3D Computer Graphics”, 3^(rd) Edition, Alan Watt, Addison-Wesley, 2000.

Typically, a computer-generated 3D graphical figure is generated in theform of a mesh of polygons that define the shape of a 3D object and atexture which is laid across the mesh using a texture mapping process.Herein, the term “graphical object” may refer to a graphical figure, asingle vertex, group of vertices, a “sprite” (collection of pixels) orparameter to a “Bezier patch” or “n patch” function object. A number ofseparate graphical objects may be combined into a fewer number oflogical objects, e.g. walls and floors may be defined as being a singleobject and thus coated with the same texture. Herein, the term “flatcolour” refers to a single colour, without variation across its surface.

With reference to FIG. 1, a system for interactive applications inaccordance with the present invention 10 has an instruction interceptionmodule 11, a main graphics processor 12, a subsidiary graphics processor13 responsive to the instruction interception module, and an encoder 14responsive to the graphics processors. In this embodiment the encoder isa DSP, alternatively the encoder may be a graphics processor, any CPU,or other processing device. In this embodiment the instructioninterception module is a device driver, alternatively the instructioninterception module is an addition to existing middleware, such asDirectX™ or OpenGL™. In this embodiment, one instruction interceptionmodule feeds two graphics processors, but in another embodiment, theremay be more than one instruction interception module, e.g. one pergraphics processor. The main graphics processor and the subsidiarygraphics processor are graphics processor modules. They may be separatehardware units, or separate processes executed on one hardware unit.

FIG. 2 shows a typical pipeline for the processing of a game comprisinggames software 21, 3D graphics middleware 22, a device driver 23, adedicated graphics processor card 24, a rendered image 25, and acompression system or encoder 26. The dotted lines A to E denote thedifferent sources of information that may be used by the encodingprocess in the compression sub-system.

Because of the immense processing power required to render the complexscenes of a typical game, the graphics are normally rendered by adedicated graphics processor chip. In a PC the chip normally resides ona separate card and in a console it is a separate chip in the main box.

The games software 21 feeds the graphics processor 24 with a 3D scenedescription, including the 3D co-ordinates of points describing objects,their position in 3D space, how they are to be distorted (e.g. a dent ina racing car), what skins ('textures') they are to be covered with, howthey are to be lit or shaded (and hence the textures further altered).Following a large amount of processing, a fully rendered 2D image 25 isproduced suitable for viewing on a device such as a computer monitor.

FIG. 3 shows a typical processing flow of rendering a scene by agraphics processor. The steps are: transformation 31 including movementand distortion of shapes; lighting 32 including lighting and shading ofa scene; set-up and clipping 33 involving working out which objectobscures others; and rendering 34 that is the drawing of the finalscene.

With reference to FIG. 2, a difficulty in trying to obtain informationabout the shape and position of objects before the graphics processor(paths C to E) is that the position and shape of the object will nothave been determined until it has been through the transformation step31 of the graphics processor. As the objects lie in 3D space, knowledgeof which objects are overlapped by others is not available untilrendered by the graphics processor.

Taking the information from source A would mean that parallel processingcannot be performed and taking the information from source B, thegraphics processor, would mean having to develop a new graphics chipinstead of using the best already available on the market at any pointin time.

With reference to FIG. 1, in the present invention an instructioninterception module 11 feeds a subsidiary graphics processor.

In this topology the main graphics processor 12 is a standard device asused in popular computer graphics cards or games consoles and operatesas normal. The subsidiary processors operate in parallel but are fed adifferent set of instructions according to the requirements of theencoder.

Object Identification

To determine the shape and position of individual graphics objects, theinstruction interception module 11 is designed so as to feed the same 3Dscene instructions to a subsidiary graphics processor 13 but with thelighting and shading aspects turned off or altered so as to minimisealterations of the textures in a scene. Instead of applying textures,the second processor is instructed to render each shape using a unique,flat colour. Alternatively, it may have an aspect of the colour thatmakes it unique, such as by using a preset bit-range of thetextures/colours to uniquely identify an object. It is then a relativelysimple task for the compression encoder 14 to determine the shapes andpositions of objects and use this information to pick out the individualobjects from the properly rendered image that had been produced by themain graphics processor 12.

In the logic used by the graphics card, the bit-range may cross over theboundary of the range used to describe, say, the blue and red elementsof a colour; the whole green range and parts of the blue range may befree to change.

The encoder may comprise of two elements: a pre-processor that workswith the subsidiary graphical processor unit (GPU) to extract certaindetails such as motion vectors; and a ‘pure’ encoder that receives‘short cuts’ from the pre-processor. This enables the use of off theshelf MPEG-4 encoders. The pre-processor may be software that runs onthe same processor as the encoder, the instruction interception module,the games processor or a separate processor.

A pre-determined range of colours, shades or colour content could beused to signify that a given shape was translucent. (MPEG-4 allows forobjects to be either solid or to have one of 255 levels oftransparency).

Furthermore, the direct feed-forward path 15 from the instructioninterception module to the encoder could be used to allow the encoder todetect complete scene changes. In such cases that scene should not becompressed as a difference from a previous image (temporal compression)as the differences would be too great.

Although cheaper chips could be used, ideally the subsidiary processoris substantially exactly the same as the main processor, so as to avoidany mismatches between the images rendered, and operates at the sameresolution as the main processor.

A number of these subsidiary processors may be used; the number willdepend on the encoding technology being used, cost, space and powerconsiderations. As an alternative to having one processor for each pieceof information required by the encoder, if the processors and encoderwere fast enough, fewer or indeed potentially only one graphicsprocessor could be used. Hence more than one graphics processor functioncould be implemented with one unit of dedicated graphics processorhardware. In this scenario, the graphics processors could be clocked torender frames more quickly than the final display rate and the resultsstored in buffer memory in a series of adjacent, non-overlappinglocations for the encoder to work on. Handshake signalling between theencoder and the instruction interception module would co-ordinate theprocesses.

Motion Estimation

The most computationally intensive element of MPEG-4 compression is‘motion estimation’ which consumes between 50% and 80% of the processingpower.

One of the methods of compressing moving video is in looking forsimilarities between subsequent frames of video. In an example of aperson walking across a field, if the camera is still, then for eachframe of video the field will be almost identical. The major changeswould occur between where the person was in one frame and where heappears a split second later in the subsequent frame.

In conventional motion estimation the screen is divided into blocks andthen compared with blocks of the previous frame, looking for as close amatch as possible. Once identified, instead of transmitting the entireblock a signal can be transmitted to the decoder that a particular blockcan be found in a previously transmitted frame but at a given offsetfrom where it should appear in the new frame. This offset is called amotion vector.

Each of these blocks can be just 8×8 pixels. To conduct a search theencoder would first have to look at an offset of just one pixel to theleft, subtract each of the 64 pixels of that block from those of thetest block, then move one pixel to the left and one pixel up, andsubtract all 64 pixels again and compare the results. In a fast movingscene, the offset could be say, 100 pixels away in any direction. Thisprocess is thus computationally intensive.

However, in the case of the graphics server of the present invention, toreduce the complexity the subsidiary graphics processor is used to coateach of the 3D objects with a new texture (a coating, or ‘skin’). Thesetextures have one aspect of their colours vary in the horizontalposition and another vary in the vertical position. If a fixed point istaken on the screen and the pixels of the texture of the object comparedat that position between two consecutive frames, it can be determined inwhich direction that object has moved. So, for example, if that pixelhas a higher colour value in the red component, it is detected that ithas moved to the right. If it has a higher colour value in the bluecomponent, it is detected that it has moved downwards.

According to one embodiment of the present invention, 32-bit pixels areused (a ‘bit’ being a binary digit, equalling either 0 or 1). Thefollowing is an example of how these bits might be allocated in eachpixel:

uuuuuuuuu aaaaaaaa yyyyyyy xxxxxxx

10×u (unique code for each object/texture combo)

8×a (alpha—used to denote transparency. 255=opaque)

7×X (variation of texture in the x axis)

7×Y (variation of texture in the y axis)

So, using an example, but in decimal to make it easier to understand,and only considering the x and y digits, the following pattern may beused:

11 12 13 14 21 22 23 24 31 32 33 34 41 42 43 44

In this example pattern above, one may consider one pixel placed onedown and third from the left. In this frame it holds the number 23. Ifin the next frame the object had moved to the left by one pixel theapparatus would detect the number 24 in the same position on the screen.As the ‘x’ digit had increased from 3 to 4, the movement is detected asbeing 1 pixel to the left. If the ‘y’ digit, namely ‘2’ had decreased to1, the object has moved down by one pixel.

These numbers are interpreted by the graphics card as colours, so in a32-bit pixel, the 12 upper-most pixels may be reserved for red, the next10 for blue and the last 10 for green.

Motion vectors are calculated on a block by block basis, either 8×8 or16×16, in the current version of MPEG-4. Such motion vectors may becalculated by taking an average of all the x elements and an average ofall the y elements.

This block based information may be used to get a motion vector for anentire object (or part of one) by detecting which pixels in each of theblocks belong to a given object and averaging them to deduce the motionvector(s) of that object. (An object may have more than one vector, e.g.a person walking will have limbs moving differently to the body).

Where an object has no sub-elements that might move separately, thenonce the motion vector is calculated for that object in one block, theapparatus may instantly deduce the motion vector of another block inwhich that object occupies the majority of pixels.

Motion vectors are applied on a block or macroblock basis. The encoderis adapted to generate a motion vector for an entire block byaggregating the motion vectors of the parts of the objects that occupythat block. In one embodiment, this involves calculating the motionvector of each pixel for each object in a block then calculating themotion vector of each object within that block (which may be differentfor the entire object over the whole screen) and then calculating themotion vector of that block using a weighted average of the objectswithin that block.

Typically the entire object includes all the blocks that are deemed tobe associated with an object by the encoder whether or not one of theseblocks actually contains a pixel that belongs to that object. The motionvector therefore applies to all of the blocks.

When encoding objects (rather than just using objects internally), theyare defined as a bounding rectangle such that that rectangle conforms tothe grid of 16×16 pixel macroblocks. Many blocks or macroblocks may betotally empty but belong to that Video Object Plane, and hence thatobject.

In one embodiment, instead of wrapping each object with a uniquetexture, the method involves projecting a single, screen-sized textureonto the scene, much like a slide projector, and then blending (i.e.binding) that texture with the blank surfaces of all the objects in ascene. The objects' surfaces have been ‘cleaned’ and replaced with flat,unique colours beforehand so that individual objects can be identified.The blending process combines the projected, ‘reference’, texture withthe objects' surfaces to produce unique textures on each object.Movement causes a ‘tear’ in this projected ‘fabric’ and so movement canbe easily detected. The reference grid is located at the same positionas the viewer.

This last method involves projecting a texture onto the entire scene.This process comprises of first determining a “projection matrix” whichmaps the texture onto the back plane (the furthest visible plane in thescene). This matrix is then used on each object so as to set its texturemappings to the projected texture. The underlying steps will be familiarto a person skilled in the art of graphics programming.

If the projected texture had the following pattern:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 2728 29 30

Then after movement by 1 pixel to the left by a 3×3 pixel square in themid-left of the pattern, the following pattern is attained:

1 2 3 4 5 6 8 9 10 0 11 12 14 15 16 0 17 18 20 21 22 0 23 24 25 26 27 2829 30

One calculation pass is used to project the texture, the scene is movedand the GPU performs the transformation calculations and moves thepixels on the screen—this is a second pass. The scene is then reset, byremoving the projected texture and resetting the objects' surfaces totheir initial states and re-projecting the texture. The whole processtakes two passes (the re-setting and projecting happen in one pass).

Each of the objects may be pre-coloured with a unique, flat colour andwhen applying the grid texture, combining the texture with these coloursto produce a unique texture for each object (e.g. the red channel isreserved to produce a unique colour for each object and the otherchannels are reserved to produce the grid texture).

In one embodiment, these methods are implemented by an instructioninterception function feeding instructions to a subsidiary graphicsprocessor module that cause it to generate new object textures. Theseinstructions cause it to generate a single texture that covers theentire image frame and binds to the surfaces of the objects in saidimage frame to produce new object textures. The single texture isprojected onto or reflected from the image frame. The step of generatinga single texture may include setting the surface of an object to adefault and then altering the single texture so as to create and apply anew surface texture for the object. The default indicates whether theobject is translucent and is unique to each object in an image frame.The encoder determines the shape and position of objects based on thenew object textures.

The invention provides a way to associate a 3D object with its 2D screenrepresentation and to identify not only motion but the amount anddirection of the motion. The preferred embodiment is to use a projectivetexture to cast a reference grid on a scene. A texture is defined thathas the same dimensions as the screen and project it from a point at thesame position as camera. The effect will be that the entire scene willbe covered by the texture.

A texel is a single element within a texture, similar to a pixel being asingle screen element. Each texel of the projective texture may, in thisembodiment of the invention, be split into a unique X and a Y componentrepresentative of its position in the texture. Various texture formatscan be selected to accomplish this. The most common 32 bit textureformats typically have a red, green, blue, and alpha components, eachoccupying 8 bits. More suitable formats such as 10-bit colours or evenfloating point colours exist, but currently are not as widely supported.

By projecting such a grid on the scene a reference grid is provided thatcorresponds exactly with the pixel locations of the screen. Byprojecting this texture before any movement has occurred and thencomparing the result against the original after movement then not onlycan it be detected that motion has occurred but also by how many pixelsand what the x and y components of that motion are.

FIG. 4 shows a texture being projected onto a simple 3D scene. Thedotted lines on the screen 42 show the outlines 44 of the 2Drepresentations of the two 3D cubes 46 that comprise the scene with itsbackground 48.

In order to track motion, a method of storing the current state of thepositions of objects relative to the screen is provided, which should doso to a relatively fine level of resolution.

Data that could be used are the object vertices, the texels that formthe surface of an object, or the variables that are used to create ormove the polygons or texels.

One method of accomplishing this is to allocate a texture to store thescreen position of the object across its surfaces—a “texture cache”.Each texel in this texture will store a representation of its screenposition, determined by projection of the reference texture duringrendering. Care must be taken in selecting the size of the texture inorder to yield a high enough sampling resolution across the surfaces.Since the apparatus tracks the movement of pixels on the screen that isoccurring in the original image, a constant texel to pixel ratio ispreferred. Thus, the texture cache used is the same size as the originaltexture that had been allocated to that object. The original game mayhave allocated more than one texture to cover various parts of an objectwhere a texture is tiled (repeated) across an object's surface. In thecase of tiling the texture cache is made larger by the same multiple asthe original texture is repeated across that object's surface.

Using projective texture mapping with the reference grid as theprojected texture allows the apparatus, on a per texel basis, toidentify where on the screen that texel would appear if it were in the‘real’ image (i.e. the one the original programmer had intended).

When the object moves, the texture mapping of the texture cache alsochanges so that it now corresponds to its new position and this fact isconfirmed by the fact that it now contains a different set of referencegrid texels. The primary texture now ‘knows’ where the object's texelsare in terms of 2D screen co-ordinates and the storage texture ‘knows’where it was in the previous frame.

The screen position is sampled from within texture space, so the normalrendering pipeline cannot be used, as it results in screen space. Inother words, the screen space position is rendered into the texture,instead of the normal way of things which is to render the texture intoscreen space, i.e. produce an image on the screen. When the objectmoves, the texture mapping of the texture cache will also change so thatit now corresponds to its new position. The cache will therefore‘remember’ the orientation of its texels with regard to the screen.

Two texture caches are, in this embodiment, maintained: one for theprevious frame, and one for the current frame. In an alternativeembodiment only one may be used per object or even only one for allobjects whereby objects are allocated a portion of a texture instead ofthe whole texture.

For each frame, render targets may be swapped once at the beginning ofthe scene to a different texture cache, and the current positions arerendered into that cache. The other cache will still have the previousframe's screen positions. On a per texel basis, then, a subtractionfinds the exact screen movement of that texel from the previous frame tothis frame. Programmable pipeline hardware can be used to render thetexel differences of the current scene into an area accessible by thevideo encoder for use in completion of the compression sequence. Thedata stored in this area is the exact motion of the texels thatrepresented each pixel and hence the motion of that pixel.

Since both the texture caches are bound to the object vertices in thesame way they will not shift relative to each other. This techniquetherefore works with movement in the x, y or z axes as well as rotationor distortion through morphing.

Since some parts of a texture may be reused in a mapping, such as theexample of a half-face texture being mapped twice, the inventionprovides a method of making sure a “unique texture space” is used, i.e.one in which there are no overlaps. Otherwise, for each time the texelappears in the image, its current value will be overwritten with the newscreen position, and the apparatus would know of only one location ofthe texel (the last to be rendered), as opposed to all the locations ofthe texel. To overcome this limitation means having to re-map thevertices to a new texture by copying the original texture to a newtexture. This method may be performed by doubling the size of theoriginal texture and adding a constant offset to the vertices thatreferred to previously mapped areas.

The new texture may be squeezed back to the size of the original andthus shrink the original polygons. Alternatively the original polygondimensions could be retained but the remapping re-arranged so as not tohave so much unused space.

A further method would be to keep the texture caches the same size asthe original texture. However, if N triangles are mapped to the originaltexture, then the caches would be divided into N rectangles. Theserectangles would then be divided into two so that there were twice thenumber of triangles as the original.

The system may then run through all the triangles that are mapped to theoriginal and assign them one of the triangles in each of the texturecaches. The fact that the relative positions have changed when beingremapped is not problematic as the texture caches are used to render toand hence only require a “unique texture space”.

Overview of Implementation

Reference is now made to FIG. 5, which illustrates the main componentsof a system implementing the present invention. The components include abank 50 of centralised games servers serving a plurality of userstations such as television terminal 52. The centralised servers anduser stations are connected via one, or more, data communicationsnetworks 54, such as a cable or satellite broadcasting network and/or apublic telephone network. A set top box 56 is provided for, amongstother functions, decoding the compressed video data. A user input device58, such as a joystick, is provided for detecting user input during agame. The network or networks 54 provide for the transmission ofcompressed video data 60 from the centralised servers 50 to the userterminals, where the set top box 56 converts the signal to adecompressed video signal 62, and the transmission of user input 64 inthe other direction.

FIG. 6 schematically illustrates features of an embodiment of a singlegame server in the bank 50 of game servers. User input 64 comes inthrough a network interface 70 into a central processing unit (CPU) 72of a conventional personal computer (PC), on which is running aconventional PC game program. The game programs sends a first set ofgraphics instructions to a first graphics processing unit (GPU1) 76which is intercepted by an instruction interception module 74, which maybe embodied as a software wrapper or hardware form. The first set ofinstructions, including vertex data, transformation data and texturedata are passed to GPU1 76 whilst a specially manipulated version of theinstructions is generated and passed to a second graphics processingunit (GPU2) 78. Both the GPUs may be provided on a common graphics card.GPU1 76 renders the image data as the game intended whilst GPU2 78 isused to render specially adapted graphics data from which to extractcompression assistance data used for compression, e.g. motion vectors.Each image frame is to be divided into blocks of pixels and then foreach block, where possible, the x,y co-ordinates of that block of pixelsare found in the previous image frame. A Digital Signal Processing unit(DSP) 84 uses the compression assistance data from GPU2 to compress theimage data from GPU1, using a known video compression algorithm, such asMPEG-4, and passes the resulting compressed video stream 86 to the CPU72 for transmission across the network 54. Handshake signalling 88between the DSP 88 and the CPU 72 is used for quality control if thereis congestion on the network.

Note, in relation to the above that the functions of the DSP 88 can bereplaced by another CPU or even a different time slice on the CPU 72.Further, GPU2 78 can alternatively be embodied using another time sliceon GPU1 76.

The method of the preferred embodiment allows the movement of objects tobe tracked and hence the movement of the pixels, on the 2D screen.Knowledge of the shape and position of a 2D, screen representation of an‘object’ is also useful for another compression technique aside frommotion estimation. MPEG-4 provides for the possibility of encodingarbitrarily shaped objects. Amongst other benefits this allows the‘blockiness’ at the periphery of a shape to be reduced.

It is important to note that the task at this level is to identify thebest possible match between a block of pixels in the current frame and ablock in the previous frame. It does not have to be an exact match. Theencoder can then decide whether it is a good enough match to encode thatblock in inter-frame mode or to use an intra-frame technique.

A further embodiment of the invention will now be described withreference to FIGS. 7 to 10. The latest graphics chips now haveprogrammable transform and lighting stages instead of (and as well as)the previous fixed graphics pipelines.

These are often referred to as “vertex shaders” (VS) and “pixel shaders”(PS) by Microsoft®. They are sometimes also referred to as “vertexprogram”, “fragment program”, “vertex processor” or “fragment processor”by other organisations.

The VS handles all the functions that deal with the moving andtransforming of vertices (the 3D points that describe the structure ofan object) as well as the lighting, colour and the texture mappingco-ordinates. The PS however deals with such things as textures and howthey are applied to objects and some lighting.

Whereas before, a games programmer had to use the fixed pipeline—i.e. anon-configurable process—by using the VS he now has the ability to writea short program (programmable pipeline module) that will execute on thegraphics processing unit (GPU).

The game communicates with the VS by first loading a program and thenpassing in data through a number of “constant” registers. It then passesvertex data through some “input” registers and executes the vertexprogram. The resulting, transformed vertices then appear in “output”registers. However these registers do not contain data that correspondsto 2D screen co-ordinates but instead as “reciprocal homogenousco-ordinates”. Another stage of the GPU pipeline called the “stepper”converts these to 2D screen co-ordinates and clips the verticesaccording to whether or not they lie within the field of view(“frustum”).

To track the motion of pixels across the screen therefore only thechanges to the vertices need to be determined after they have beenthrough the transformation stage. To get a pixel-level resolution theapparatus then interpolates across that polygon's surface using the sametechniques as would normally be used to apply a texture to the surfaceof an object. That interpolation function is part of the standardprocessing pipeline of a GPU.

One way of processing the vertices would be to store them after theyhave been transformed by the VS and then subtract the vertices of twoconsecutive frames to calculate the screen movement. This is a viableproposition but then the issue of generating unique texture space shouldalso be resolved.

Alternatively the apparatus could take the difference between the inputparameters and process those to end up with the difference between avertex over two frames. The apparatus thus store all the variables thatare used in determining the transformation process of a vertex from theprevious frame and then feed them into a new VS program at the same timeas the variables used to transform the vertex of the current frame.

In frame 0 the apparatus stores the input variables. In the processingfor frame 1, frame 0's variables plus frame 1's variables are input. Thealtered VS program is very similar to the original except that afterhaving calculated the transformation of a vertex as was intended by theoriginal game programmer, it has been altered so that it will alsoprocess the previous frame's vertex using variables stored in differentregisters. It will then go on to calculate the difference between thesetwo vertices and output that result instead of a single, transformedvertex as was originally intended.

FIG. 7 shows a standard vertex shader 102. Note that the input vertexdata 104 and vertex shader constants 106 could be in any order. Theselection of which constants refer to colour information, lighting,vertex positions, or otherwise is unknown. However, the outputs 108 aredefined: oPos is the ‘screenspace’ position of the vertex, oD0 is thediffuse colour, oD1 is the specular colour, oT0 up to oT3 are four pairsof texture coordinates. oFog is the range of the fog and oPts is thepoint size for the point sprite processor.

In order to determine which inputs (“vertex shader constants”) and whichinstructions in the VS program are used to determine the new positionsof the vertices, the process begins with the output, oPos and worksbackwards.

With reference to FIG. 8, in the graphics pipeline 200, a game programon the CPU 202 is shown with a DirectX wrapper 204 and storage forparameters 26. The vertex shader 208 outputs both transformed verticesand motion vectors 210.

With reference to FIG. 9, the steps 300 of the system are shown inprocessing the first frame, F0.

First 302, The primary (original) VS program is analysed by the DXwrapper and a new, associated program created. Here the process analysesthe original VS program, determines which of the instructions and inputparameters deal purely with the position of a vertex and creates a newVS program.

The original VS program is then loaded 304 onto GPU.

Next 306, F0 data is loaded as parameters into VS program and a copy ismade. All the input parameters used by the original VS program thataffect a vertex's position in F0 are stored.

A single vertex of the model is loaded and processed 308. One vertex ofthe model transformed into screen space is now available (It is actuallya 4-D vector in canonical device co-ordinates and another name for it isreciprocal homogenous co-ordinates, RHC, this is converted to screenco-ordinates by a “stepper”).

Finally 310, if more vertices of model left, go back to step 306.

With reference to FIG. 10, the steps 400 of the system are shown inprocessing the second, F1, and subsequent frames.

The original VS program is loaded 402 onto GPU.

Next, 404, F1 data loaded as parameters into VS program a copy is made.All the input parameters used by the original VS program that affect avertex's position in F1 are stored for processing of subsequent frames.

A single vertex of model loaded and processed 408.

The previously created new, associated VS program is loaded 410.

The input parameters relating to a vertex position from the previousframe, F0, and the parameters for the current frame, F1, are loaded 412into the new VS program then the same vertex is processed 414 using F0data and then F1 data and the difference is output. The new VS programprocesses these two frames' worth of vertices in one pass, subtracts thetwo results and outputs it through the normal output register of the VS.

If more vertices of the model are left 416, go back 418 to step 402.

Instead of loading and unloading two VS programs, one possibility is tojoin the two to make one big VS program. An input parameter or aninternal variable is used to jump to the appropriate part of the programaccording to whether the motion vector is to be calculated the image isto be rendered. Using one VS program halves the render state changes(i.e. the system can loop back 420 to step 404) and thus speeds thingsup slightly.

The rest of the rendering pipeline then continues as normal with the“Stepper” interpolating across a polygon, culling occluded pixels andhanding over to the pixel shader for rendering into memory. The onlydifference is that instead of rendering into screen memory, the pipelineis instructed to render into a different memory location.

Optionally, the two transformed vertices may be output instead of thedifferences.

The whole of this process is called “parameterisation” and thedetermining of which parts of the existing VS are relevant to us isknown as “register colouring”. These techniques are used in compilertheory.

The benefits are in using existing hardware and in avoiding having torecompile the game code and this is done by altering the existing gamecode specifically by:

the use of register colouring in the context of modifying an existinggame program to ultimately determine “information useful forcompression”. This step is essentially used so as to lessen the amountof input parameters to be stored and then fed into the new VS program asthere are only a limited number of input registers. It also allows us toshorten the new VS program by avoiding copying the instructions thatdetermine lighting or colouring of vertices. It is not essential thatthis is done, but it would be wasteful without it and the risk existsthat the new VS program would be too large for the GPU or that too manyinput registers would be needed which the GPU didn't possess;

the use of the vertex shader to determine motion vectors; and

determining which parameters influence the position transformation of avertex and storing them for processing later.

Vertices could be created dynamically by the game code and sent to theGPU in any order. Some way of recognising them between frames so thatthe correct pair are subtracted is required. This can be achieved bycreating a signature for each vertex. The signature is made up ofeverything (or at least a number of things) that are used in renderingthat vertex, for example which VS program is used to process it.

Current GPU hardware cannot store post-transformed vertices so if thereare any complex special effects that require multiple passes this meansthat the vertex transformations will have to be calculated each time. Ifit is really complex then the programmer may opt to do thosetransformations on the CPU instead.

Optionally, a cache may be used to store post-transformed verticesbetween two or more frames (for use in determining motion vectors).

Normally, a single pass through a VS processes only a single vertex. AGPU may have several VSes that works in parallel but they all use thesame render target. To calculate the difference between two verticeswould mean swapping the render target. The normal process would be toload vertex 1, run the original VS, load and run the modified VSprogram, then load the original VS program again, load vertex 2 etc.Swapping targets and render states are overheads and doing so for everyvertex would slow the overall processing considerably.

To minimise the delay, all the input details for that complete objectmay be stored and arranged so that the render target is changed onlyonce before the vertices are processed. This would reduce both thenumber of render state changes and render target changes.

Another way of reducing state changes would be to have a single VSprogram. The process could combine the original VS program with the newpart to make a larger program and then use one of the input constants asa switch so the single new VS knows which part of its code to process:the original or the new addition. The GPU can only render one pixel at atime so both VS programs may not be processed at the same time. Thusthere may be more than one VS program.

Furthermore, instead of having two distinct render targets, the processcould have just one that was twice as large as the screen and simplydirect the desired image to one half and the difference between verticesdata to the other half. This would also help us use only one GPU insteadof two. Alternatively the process could embed the two pieces ofinformation in a single image by restricting the rendered image to onerange of colours and the difference between vertices data to anotherrange.

For parameterisation to work it assumes that there is enough space forthe altered VS program and that there are enough registers to pass intwo sets of variables. That will largely depend on the VS program andthe capabilities of graphics chip. However, there are things that can bedone to help us ensure that the process does not run into problems.

The first is that when the host game program interrogates the devicedriver of the GPU to ask what capabilities it has, the process can statethat the GPU has a smaller VS program store and fewer registers to storevariables than that GPU actually supports.

At any one point in time there is a large variation in the graphicscards that are used by end consumers. And so games software musttherefore cope with a variety of different capabilities. It is thereforecommon practice for a game to check the facilities offered by a GPUbefore trying to invoke one. By stating that the GPU is of a lowersophistication the chances of breaking the game are lessened. Instead,the game would adapt by either dropping that graphical feature or bypassing that set of commands to the host CPU instead. The result mayonly be a minor diminishing of the graphical special effects rather thana break-down of the games program altogether.

As stated earlier, as well as doing vertex transformation calculations,a VS also deals with aspects such as lighting. Some of the VS programand some registers would therefore be used in a way that has no affecton the motion of pixels on the screen. To reduce the number of registersneeded and to make the modified version of the VS program run faster theexisting VS program is pre-analysed to determine which parts arerelevant.

Sorting out what is and isn't relevant isn't straightforward if thereisn't any prior knowledge of the game programmer's intentions, as theinput registers aren't segregated. However, in normal operation the VSprogram will output a transformed vertex using a pre-designated register(which will then be used as the input to another stage in the overallgraphics pipeline). Armed with that knowledge the process can workbackwards through the VS program and identify every instruction andmemory location that has an influence on a vertex co-ordinate, thusbuilding a “dependency graph”. From this the process can identify therelevant instructions and input registers. This is a well known problemin compiler theory, and is called “register colouring”. The process canthen strip out any unwanted instructions.

A GPU may also support a fixed graphics pipeline as well as theprogrammable type described above. For the techniques described to workthe process would have to first produce a PS and VS programs thatmimicked the processes of the instructions that would have used thefixed pipeline. These would then be used to replace the original fixedpipeline instructions before applying the techniques of the invention ofmotion vector generation.

Methods are well known to produce a single block-based motion vectorfrom a group of pixel-based motion vectors and to decide between interand intra coding.

This embodiment of the present invention has the following features:

-   -   using the post-transformed vertices of two frames to calculate        motion vectors of pixels on the screen.    -   doing so by first storing them in memory in such a way that the        vertices no longer overlap and then subtracting the two sets of        vertices from each other to get the differences    -   using the vertex shader to process the differences in the input        variables in order to generate the difference between vertices        over two frames.

The “vertex shader” is a type of “programmable pipeline” as is a “pixelshader”.

-   -   using the vertex shader and/or pixel shader to determine the        differences in colour and or luminance over two frames    -   using a larger render target so that the real image and the        differences between vertices may be stored as the same “render        target”    -   recording of input parameters for processing later so the        process doesn't need to keep swapping render targets    -   analysing the vertex shader program and altering it so as to        isolate only those instructions and data that influence the        vertex positions themselves    -   lie to the host games program when it interrogates the GPU for        its capabilities    -   using the above techniques within only one or more than one        VS/PS/GPU (i.e. hacking the existing code in a single GPU,        running a new processing cycle with the new code, or using        another GPU altogether to run the new code)    -   extrapolating the differences between vertices over the surfaces        of the polygons so as to get “motion vectors” that correspond        with the screen pixels.

Differences don't have to be between two consecutive frames—they couldbe any two frames.

GPUs can have more than one VS and/or PS.

Instead of polygons a game may describe an object using such techniquesas “Bezier patches” or “n patches” meaning that mathematical functionsare used to describe 3D surfaces instead. Instead of tracking discretevertices the process may therefore have to track the input variables tohigher-level shape description functions.

The techniques of the present invention could be used for 2D objectssuch as billboards, not just 3D ones.

Optionally the method may be modified to encompass the use of tags withvertices so that it is easier to relate the same vertex between twoframes. Some games use dynamically generated vertices to describescenes. As it is not certain that they will be produced by the game inthe same order the process cannot be sure that when the process isdetermining the difference between two vertices that in fact the processis dealing with the same point of the same object in both cases.

Optionally, instead of tracking all the vertices the process couldinstead track a lower resolution model such as a simple bounding box oreven just two points in space that represent the extremes of the zpositions of an object. The process could then apply the transformationfunctions to these points (maybe in the CPU) and simply extrapolatethose post-transformed results to the pre-transformed vertices of theobject.

An advantage of the present invention is that it exploits the fact thatwith synthetic images there is, by the particular methods and meansprovided by the invention, access to information relating to the imagesprior to its rendering and that this information can facilitate thecompression process. By processing this information in parallel with therendering of that image the speed of compression and hence reduce thelatency of the system can be improved.

Further modifications and improvements may be added without departingfrom the scope of the invention herein described.

1. A method of generating a plurality of compressed image data signals,comprising the steps of: a) outputting instructions from a plurality ofgraphics generating computer programs; b) providing supplementaryinstructions; c) processing at least one of the outputted instructionsor at least one of the supplementary instructions or a combinationthereof to generate graphics data comprising a plurality of pixels; d)processing at least one of the supplementary instructions to generatecompression assistance data responsive to at least one differencebetween at least one of the outputted instructions and at least anotherof the outputted instructions; e) processing a plurality of sets of thepixels using at least a portion of the compression assistance data togenerate the compressed image data signals; and, f) transmitting thecompressed image data signals to a plurality of remote processingdevices to be decompressed therein.
 2. The method as claimed in claim 1wherein: i) the compression assistance data comprises details of sets ofpixels to be processed in step (e); ii) the details of the sets ofpixels to be processed are generated by step (d); iii) the details ofthe sets of pixels to be processed are used in step (e); and, iv) thegeneration of the details of the sets of pixels to be processed occursbefore the sets of pixels to be processed are generated.
 3. The methodas claimed in claim 2 wherein at least one of the outputted instructionsis intercepted by a wrapper before the compression assistance data isgenerated.
 4. The method as claimed in claim 3 wherein at least one ofthe outputted instructions is a DirectX instruction and at least part ofthe processing in step (c) occurs in a graphics processor module.
 5. Themethod as claimed in claim 4 wherein at least a portion of the graphicsdata is at least partially compressed by the graphics processor moduleby processing at least one of the supplementary instructions in thegraphics processor module.
 6. The method as claimed in claim 4 whereinthe supplementary instructions comprise instructions that causes theprocessing in step (c) to store the plurality of pixels that correspondto the outputted instructions of a first of the graphics generatingcomputer programs, in memory locations that do not overlap a majority orall memory locations that contain the plurality of pixels thatcorrespond to the outputted instructions of a second of the graphicsgenerating computer programs.
 7. The method as claimed in claim 2wherein the supplementary instructions comprise instructions that causesthe processing in step (c) to store the plurality of pixels thatcorrespond to the outputted instructions of a first of the graphicsgenerating computer programs, in memory locations that do not overlap amajority or all memory locations that contain the plurality of pixelsthat correspond to the outputted instructions of a second of thegraphics generating computer programs.
 8. The method as claimed in claim1 wherein at least one of the outputted instructions is a DirectXinstruction and at least part of the processing in step (c) occurs in agraphics processor module.
 9. The method as claimed in claim 8 whereinat least one of the outputted instructions is intercepted by a wrapperbefore the compression assistance data is generated.
 10. The method asclaimed in claim 8 wherein the processing in step (e) further comprisesdetermining motion vectors corresponding to at least one of theplurality of pixels and its relative position between frames.
 11. Themethod as claimed in claim 8 wherein: i) the compression assistance datacomprises details of sets of pixels to be processed in step (e); ii) thedetails of the sets of pixels to be processed are generated by step (d);iii) the details of the sets of pixels to be processed are used in step(e); and, iv) the generation of the details of the sets of pixels to beprocessed occurs before the sets of pixels to be processed aregenerated.
 12. The method as claimed in claim 10 wherein: i) thecompression assistance data comprises details of sets of pixels to beprocessed in step (e); ii) the details of the sets of pixels to beprocessed are generated by step (d); iii) the details of the sets ofpixels to be processed are used in step (e); and, iv) the generation ofthe details of the sets of pixels to be processed occurs before the setsof pixels to be processed are generated.
 13. A method of generating aplurality of compressed image data signals, comprising the steps of: a)outputting instructions from a plurality of graphics generating computerprograms; b) providing supplementary instructions; c) processing atleast one of the outputted instructions or at least one of thesupplementary instructions or a combination thereof to generate graphicsdata comprising a plurality of pixels; d) processing at least one of thesupplementary instructions to generate compression assistance dataresponsive to the type, contents or any combination thereof, of at leastone of the outputted instructions; e) processing at least a portion ofthe plurality of pixels using at least a portion of the compressionassistance data to generate the compressed image data signals; and, f)transmitting the compressed image data signals to a plurality of remoteprocessing devices to be decompressed therein.
 14. The method as claimedin claim 13 wherein: i) the compression assistance data comprisesdetails of the portion of pixels to be processed in step (e); ii) thedetails of the portion of pixels to be processed are generated by step(d); iii) the details of the portion of pixels to be processed are usedin step (e); and, iv) the generation of the details of the portion ofpixels occurs before the portion of pixels is generated.
 15. The methodas claimed in claim 14 wherein at least one of the outputtedinstructions is intercepted by a wrapper before the compressionassistance data is generated.
 16. The method as claimed in claim 15wherein at least one of the outputted instructions is a DirectXinstruction and at least part of the processing in step (c) occurs in agraphics processor module.
 17. The method as claimed in claim 16 whereinat least a portion of the graphics data is at least partially compressedby the graphics processor module by processing at least one of thesupplementary instructions in the graphics processor module.
 18. Themethod as claimed in claim 13 wherein at least one of the outputtedinstructions is a DirectX instruction and at least part of theprocessing in step (c) occurs in a graphics processor module.
 19. Themethod as claimed in claim 18 wherein at least one of the outputtedinstructions is intercepted by a wrapper before the compressionassistance data is generated.
 20. The method as claimed in claim 18wherein: i) the compression assistance data comprises details of theportion of pixels to be processed in step (e); ii) the details of theportion of pixels to be processed are generated by step (d); iii) thedetails of the portion of pixels to be processed are used in step (e);and, iv) the generation of the details of the portion of pixels occursbefore the portion of pixels is generated.
 21. The method as claimed inclaim 20 wherein the processing in step (e) further comprisesdetermining motion vectors corresponding to at least one of theplurality of pixels and its relative position between frames.
 22. Themethod as claimed in claim 18 wherein the processing in step (e) furthercomprises determining motion vectors corresponding to at least one ofthe plurality of pixels and its relative position between frames. 23.The method as claimed in claim 22 wherein the supplementary instructionscomprise instructions that causes the processing in step (c) to storethe plurality of pixels that correspond to the outputted instructions ofa first of the graphics generating computer programs in memory locationsthat do not overlap a majority or all memory locations that contain theplurality of pixels that correspond to the outputted instructions of asecond of the graphics generating computer programs.
 24. The method asclaimed in claim 10 wherein the supplementary instructions compriseinstructions that causes the processing in step (c) to store theplurality of pixels that correspond to the outputted instructions of afirst of the graphics generating computer programs in memory locationsthat do not overlap a majority or all memory locations that contain theplurality of pixels that correspond to the outputted instructions of asecond of the graphics generating computer programs.
 25. The method asclaimed in claim 16 wherein the supplementary instructions compriseinstructions that causes the processing in step (c) to store theplurality of pixels that correspond to the outputted instructions of afirst of the graphics generating computer programs, in memory locationsthat do not overlap a majority or all memory locations that contain theplurality of pixels that correspond to the outputted instructions of asecond of the graphics generating computer programs.
 26. The method asclaimed in claim 25 wherein the processing in step (e) further comprisesdetermining motion vectors corresponding to at least one of theplurality of pixels and its relative position between frames.
 27. Themethod as claimed in claim 21 wherein the supplementary instructionscomprise instructions that causes the processing in step (c) to storethe plurality of pixels that correspond to the outputted instructions ofa first of the graphics generating computer programs in memory locationsthat do not overlap a majority or all memory locations that contain theplurality of pixels that correspond to the outputted instructions of asecond of the graphics generating computer programs.